ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98b.txt/000104_icon-group-sender _Wed Jun 24 08:08:34 1998.msg

Internet Message Format | 2000-09-20 | 9KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA01691
    for <[e-mail]>; Wed, 24 Jun 1998 08:08:34 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA13548; Wed, 24 Jun 1998 08:08:23 -0700
From: [e-mail] (Frank Sergeant)
To: [e-mail]
Subject: Re: using Icon for database application
Date: Tue, 23 Jun 1998 20:03:06 -0500
Reply-To: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
Lines: 179
Errors-To: [e-mail]
Status: RO
Content-Length: 7986

Clint Jeffery, [e-mail] wrote:

> While I disagree with
> Gordon Peterson's answers to your questions on many or most points,

     I'm glad to hear that.  Even if Gordon is correct in all his
points, I'm going to have to work toward them slowly.  He does
bring up (albeit politely) the possibility, worth considering,
that I am out of my mind.

> I've done a lot more Icon
> programming than Gordon, who frequently posts about Snobol in the Icon
> group, bless his heart!

     All I know (?) about Snobol was that I'd heard over the
years that it was "good for string processing".  Now I gather it
is the father, or favorite uncle, of the Icon language.

> Icon isn't a special-purpose database language.  Its built-in types are
> designed for flexible data manipulation in main memory.  If that's what
> you want to do, you are all set;

     When you put it that way, I think it is clear that that _is_
what I want to do.  (Also, it should be perfectly suitable for
sequetial file processing, right?  That should work very well for
producing reports.)  There remains the question as to whether
the data will actually fit in RAM so that I _can_ do what I want
to do.  I'm inclined to think it will fit, but I need to do some
tests.

> if not, you should look for a database language, or think about
> connecting Icon to a third-party database engine. There's more on
> memory requirements in your question 9 below.

     I am now thinking about using the variable length,
delimited format with all the data in RAM.  If that doesn't
work out, I gather from a later comment you made that I
could write extension routines in C as modifications to the
Icon source.  I think I could do that to give Icon
direct/random access to database files.  I am set up here
with MSVC/C++, BC/C++, Watcom, and several other C compilers
(which strikes me as very strange for someone who definitely
is not a fan of C -- oh well).  Of course, I suspect there
are details to study in order to coordinate properly with
Icon, so I'd rather not rush into this.  However, I'm
familiar with the C and Win32 file access routines.  Another
possibility would seem to be doing the same thing to get
access to Win32 socket routines and use them to communicate
with a (possibly bare-bones) database server, written in
anything, possibly C.  So, I am encouraged to think the
straight forward, all Icon, data in RAM approach might work
fine but that if it doesn't, I have not necessarily painted
myself into a corner.

> >    2. I gather Windows Icon can make a normal looking
> >       Windows application (rather than a Motif-ish
> >       application) and that I probably could figure out
> >       how to do this by reviewing the source code for Wi.

> Well, you shouldn't have to learn it by studying source code.

     You understood I meant to use the source for Wi as
an example of how to put up the various menus, entry fields,
and such, right?  That is, the menus and such in the Wi
application look "normal" for Windows, whereas those in VIB
do not.  Since Wi is written in Icon, I figured it must be
possible to get that "normal" Windows look and that Wi
would show how.

> Both the on-line reference and an appendix in "Graphics
> Programming in Icon" discuss these functions, which are quite
> simple.

     I have the book on order.  I'm very much looking
forward to it.  At the moment, Python and Icon are largely
tied in my mind.  I would be delighted to hear more comments
that might help me understand their relative tradeoffs.  One
thing that worries me about Python is that its preferred GUI
seems to be Tk.  I used Tk a little (with Tcl) several years
ago, prior to it getting a "native look and feel" and wasn't
crazy about it.  Also, a demo of a extension to Tk, PMW
(Python Mega Widgets), seemed way too slow.  So, that Icon
might have an easy to use, fast GUI makes me think I will
like it better than Python with Tk.

> Icon's graphics are plenty fast enough for 486 clients, but
> Icon would not be suitable for the server software unless
> either (a) enough main memory was available to fit all the
> indices and preferably the data as well, or

     How does keeping just the indices in RAM solve the
problem if Icon does not have direct access to the data
file?

> One wart I know of at present: if you use tons of different
> record types you get penalized (this is true, for example,

     I guess I would have a record type for each database
plus other record types for anything I could treat as an
object.  On the bright side, you might well have this fixed
before I'm ready to put the app in production.

> I think the Icon program would be larger, unless your
> rewrite substantially reduces the number of lines of code to
> exploit Icon's built-in features.  If you just translated
> xBase line-by-line into Icon the result will be huge.
> Clipper is (was?) a fine commercial-quality product.

     I think I could knock perhaps a third off the source
code side by rewriting it properly in Clipper.  I would hope
to take advantage of Icon's features to make it even
smaller.  All this is guess work until I try it out.

> Ah, its time for some vaporware.  Sockets are only
> available on Unix at the present time.
 < calling Win32 routines from Icon >
> I keep getting nibbles, but so far no one has volunteered to implement this
> kind of access.  You can get the Windows Icon source and make such
> extensions yourself, and if you build something really useful I'd certainly
> like to incorporate it into the main public domain Windows Icon
> distribution.

     Ok.  I find this very encouraging.  As slowly as I am
moving, you may well have it all ready before I need it.
Or, if I do need it sooner, I might be able to write
specific calls to the socket routines.  I'll be glad to send
you anything I do in this area, but I'm a long way from it
at the moment.

     Another idea that occurred to me, if only as a proof of
concept, if sockets aren't available, would be to have the
client and server communicate via files on a RAM disk on the
server.  Another possibility might be to have the server
generate HTML and let the clients be any old web browsers.
(I have some user interface concerns here, though.)

> The main Idol web site is now www.cs.utsa.edu/research/idol/ and I am
> in the process of packaging a release of Windows Idol.  You should consider
> using Idol if you want to write object-oriented applications or have a large
> complex application with many user-defined types.

     Thanks.  I'll take a look when it is ready.

> Icon is generally tuned for speed, rather than to minimize space
> requirements.  I've heard reports of Unix Icon programs in the million line
> range, but haven't seen a Windows Icon program in the 100K range yet.

     If things go well, my rewrite would be under 100K, so
that sounds ok.

> My impression is that Windows manages virtual memory much
> worse than UNIX or Linux.

     I don't doubt it.  I'm rather annoyed with Windows at
the moment, so I'm ready to believe any bad thing about it.
Although, W95 almost never crashes on me any more now that
I fixed my hardware.  Prior to that, it would crash perhaps
one or more times a day.  But, at that same time, with the
defective hardware, I would usually run Linux for more hours
per day on the same machine and Linux would essentially
_never_ crash on me.  So, my conclusion is that with
equivalent hardware Linux is the better operating system
and goes out of its way to take care of you and your data
while Windows does not.

> On old 486's with 8MB of memory you may run into terrible
> problems unless you split the application up into a thin
> "client" program that can access a server with more muscle.

     I think I can do that.  It would be easier to say a
customer must have _one_ fast machine as a server, than to
say _every_ machine in the office must be a fast machine.

     Thanks for your other comments as well.


  -- Frank
  [e-mail]